This is a proposal to fix #2 in Approach 2, with patching code to achieve context copying on task creation, please see separate commits in this PR. Regarding context copying/inheriting:

• After importing contextvars with this PR, all create_task() calls of event loops which went through either asyncio.get_event_loop(), asyncio.new_event_loop() or asyncio.set_event_loop() would implicitly do an extra context copy, and use it as task context.
• Current PR requires less user code. User just needs to import contextvars before initializing event loop policies or creating event loops, and all tasks created by automatically patched loops could inherit the context on creation.
• But get_event_loop_policy() shall no longer return the policy passed to set_event_loop_policy() with this PR - a wrapper policy is returned. Although the wrapper works in the same way as the original policy, get_event_loop_policy().policy should be used if original policy instance is required.

Other than patching, it is also possible to use get_task_factory() and set_task_factory() to achieve the same result, as demonstrated here. Pros and cons:

• User needs to explicitly call enable_inherit(loop) for any loop in use.
• But forgetting to do so will end up with tasks behaving differently.
• However this approach doesn't patch anything, so APIs are untouched.

At last, the reason for using Approach 2 of #2 is:

1. I didn't want Approach 1 to copy lots of asyncio code from Python 3.7 into this package. But I'm still open to that, please advise.
2. Tried an Approach 3 but failed. (Created a wrapper event loop providing the new APIs, but the loop relationship is a mess - the underlying loop creates a Future whose _loop is underlying loop, but when using the wrapper loop to e.g. gather() it checks future._loop is loop and fails. Or vise versa. Also Task code needs to be backported anyway.)
3. Couldn't find a new Approach 4.

UPDATE: This is now under testing in practice as aiocontextvars 0.2 in GINO and possibly some other projects.